Sorry for taking so long to review!

Good thinking also accounting for the entities / building unlock, as well as tasks.

Is there any chance we could look into:

• Only do this for projects with activity in the last week. While we run the cron at a schedule, we should first filter down so we only run the logic on projects with recent activity (did determined from task_events entries is good enough). Of activity, continue to the unlocking logic.

• Using the updatedAt field that already exists in ODK for entities. I'm not sure we need a new field in our db. I think the ODK entites unlocking can be done via the process:

  1. Call the sync function to sync current status from ODK
  2. If there are any entities that are status 1 (open in ODK), we continue to the unlocking logic.
  3. If we call the ODK API to get entity data, including the updatedAt field (hopefully we can reuse existing functions just using different odata filters, but might need to modify slightly?). Using odata filters we should be able to get entities with updates over 1 day ago, also via the updatedAt field.

The criteria for unlocking can be found in this comment: #1603 (comment)

For the entities unlock, we could probably just base it on: if its 'open in ODK', but no activity in 1hr, then we reset the status.

Does that sound reasonable?

@spwoodcock
Both the sync api and osm fieldwork's getentitydata functions work on a single project at a time.
We would have to write some logic to get active projects and then sync data for each project in a loop.
If it is alright to do this, then there should be no other issues with this solution.

Yeah I think its OK!

This cron probably won't run really frequently, plus perhaps we can optimise in future somehow.

But I imagine there will only be at most 10-20 active projects in the last week at any one time.

Calling the ODK Central API for each is the only way unfortunately, due to the constraint of needing to support external ODK Collect instances